Migration of navigation node URL

String uri = Util.getPortalRequestContext().getPortalURI() + "home";

PortalURL nodeURL = nodeurl();
NavigationResource resource = new NavigationResource(SiteType.PORTAL, pcontext.getPortalOwner(), "home");
String uri = nodeURL.setResource(resource).toString();

UserNode node = ...;
String uri = Util.getPortalRequestContext().getPortalURI() + node.getURI()";

UserNode node = ...;
PortalURL nodeURL = nodeurl();
String uri = nodeURL.setNode(node).toString();

Security changes

Security configuration has changed in accordance with the flexibility added by the navigation controller. In particular the authentication does no longer depends on the path specified in web.xml. Instead it relies on the security mandated by the underlying resource.

Here are the noticeable changes for security

• Authentication is now triggered on the /login URL when it does not have a username or a password specified. Therefore the URL /login?initialURI=/classic/home is (more or less) equivalent to /private/classic/home

• When a resource cannot be viewed due to security constraint

  • If the user is not logged, the authentication will be triggered

  • Otherwise a special page (the usual one) will be displayed instead

Default handler

Redirection to the default portal used to be done by the index.jsp JSP page. This is no longer the case, the index.jsp has been removed and the welcome file in web.xml was removed too. Instead a specific handler in the routing table has been configured, the role of this handler is to redirect the request to default portal when no other request has been matched previously:

<controller>
 ...
 <route path="/">
  <route-param qname="gtn:handler">
   <value>default</value>
  </route-param>
 </route>
</controller>

Legacy handler

Legacy URLs such as /public/... and /private/... are now emulated to determine the best resource with the same resolution algorithm than before but instead of displaying the page, will make an http 302 redirection to the correct URL. This handler is present in the controller configuration. There is a noticeable difference between the two routes

• The public redirection attempt to find a node with the legacy resolution algorithm without authentication, which means that secured nodes will not be resolved and the redirection of a secured node will likely redirect to another page. For instance resolving the URL /public/classic/administration/registry path will likely resolve to another node if the user is not authenticated and is not part of the platform administrator group.

• The private redirection performs first an authentication before doing the redirection. In that case the /private/classic/administration/registry path will resolve be redirected to the /portal/g/:platform:administrators/administration/registry page if the user has the sufficient security rights.

Static resource handler

The "/" mapping for "default" servlet is now replaced by mapping for org.exoplatform.portal.application.PortalController servlet, that mean we need a handler (org.exoplatform.portal.application.StaticResourceRequestHandler) to serve static resources like image, css or javascript... files in portal.war. And it should be configured, and extended easily. Thanks to the controller.xml. This file can be overridden and can be changed and reloaded at runtime (WebAppController is MBean with some operations such as : reloadConfiguration() ...)

Declare StaticResourceHandler in controller.xml

<route path="/

{gtn:path}
">
<route-param qname="gtn:handler">
<value>staticResource</value>
</route-param>
<path-param encoding="preserve-path" qname="gtn:path">
<pattern>.*\.(jpg|png|gif|ico|css)</pattern>
</path-param>
</route>

The following mappings in portal.war's web.xml file are no longer required:

<servlet-mapping>
 <servlet-name>default</servlet-name>
 <URL-pattern>*.jpg</URL-pattern>
</servlet-mapping>
...

portal.war web.xml changes

DoLoginServlet declaration

<servlet>
 <servlet-name>DoLoginServlet</servlet-name>
 <servlet-class>org.exoplatform.web.login.DoLoginServlet</servlet-class>
</servlet>
<servlet-mapping>
 <servlet-name>DoLoginServlet</servlet-name>
 <URL-pattern>/dologin</URL-pattern>
</servlet-mapping>

Declare portal servlet as default Servlet

<servlet-mapping>
  <servlet-name>portal</servlet-name>
  <URL-pattern>/</URL-pattern>
</servlet-mapping>

So there are some mapping declaration for portal servlet are unused, we should also remove them: /private/* /public/* /admin/* /upload/* /download/*

Add some security constraints

<security-constraint>
 <web-resource-collection>
  <web-resource-name>user authentication</web-resource-name>
   <URL-pattern>/dologin</URL-pattern>
   <URL-pattern>/g/*</URL-pattern>
   <URL-pattern>/u/*</URL-pattern>
...
 </web-resource-collection>
</security-constraint>

We can remove the index.jsp, and its declaration in web.xml now, because of the Default request handler

<welcome-file-list>
 <welcome-file>/index.jsp</welcome-file>
</welcome-file-list>

We need to change the location of PortalLoginController:

In 5.1, web.xml contained this:

<servlet>
   <servlet-name>PortalLoginController</servlet-name>
   <servlet-class>org.exoplatform.web.login.PortalLoginController</servlet-class>
</servlet>

In 5.2 it should be:

<servlet>
   <servlet-name>PortalLoginController</servlet-name>
   <servlet-class>org.exoplatform.web.security.PortalLoginController</servlet-class>
</servlet>

Dashboard changes

There are several important changes to take in account

• dashboard are now bound to a single URL (/u/root by default) and dashboard pages are leaf of this path

• dashboard life cycle can be decoupled (create / destroy) from the identity creation in a configurable manner in UserPortalConfigService and exposed in configuration.properties under gatein.portal.idm.createuserportal and gatein.portal.idm.destroyuserportal.

• by default dashboard are not created when a user is registered

• a dashboard is created when the user access his dashboard URL

Remove unused files

• portal-unavailable.jsp: this file was presented before if user goes to a non-available portal. Now the server sends a 404 status code instead.

• portal-warning.jsp: this file is not used in any place